1. Field of the Invention
This invention relates to enterprise application integration and more particularly to apparatus and methods for improving event delivery performance in polling adapters.
2. Description of the Related Art
Adapters allow business events to flow from an Enterprise Information System (EIS) to a listening client such as a business process or other application. The Java 2 Enterprise Edition (J2EE) standard defines a standard approach to building these adapters. This approach is outlined in the J2EE Connector Architecture (JCA) specification.
The flow of information from an EIS to a client system is commonly referred to as “inbound communication.” Often, the EIS is not configured to communicate directly with the adapter. As a result, the adapter may be configured to periodically poll the EIS for new information. In many cases, a “trigger” may be put in place in the EIS system, which may be configured to write “event records” into an “event table” when data has changed in the EIS. The adapter may then poll this event table to obtain a list of changed objects, including the types of objects and their keys. The adapter may then use this information to retrieve the entire event from the EIS system, send it to the client system, and delete the event from the event table, often within the context of a transaction.
A client system may often require that events be received and processed in a certain order. Specifically, for a given object key, events related to that object key may need to be received and processed in sequence. This may be important in data synchronization scenarios because if, for example, a CREATE operation for an object occurred prior to an UPDATE operation on the same object in an EIS, the CREATE operation would also need to occur prior to the UPDATE operation in the downstream client system. If the two operations were reversed, the synchronization process between the EIS and client system would fail.
An adapter will ideally deliver events to a client as fast as possible, while ensuring that events for the same object are processed in the correct order. Some intelligence in the adapter is necessary to make this happen. In the past, many polling adapters had two modes of operation: ORDERED and UNORDERED. The ORDERED mode would address the ordering requirement by placing all polling or event delivery logic on a single thread of execution. By contrast, the UNORDERED mode would utilize multiple threads of execution (up to one per event in the poll cycle) but could not guarantee a specific order. Additionally, because only one connection to the EIS was defined, the multiple threads of execution in UNORDERED mode would contend for the connection. To prevent some of this contention, the “delete” operation in the event table would be delayed until all delivery threads finished executing.
In view of the foregoing, what is needed is a polling adapter that can guarantee the related events are delivered in order, while allowing unrelated events to be delivered in any order. Ideally, such a polling adapter could accomplish these goals while delivering events to a client in a fast and efficient manner.